This unit builds the vocabulary and the mental model for the whole course. Everything that follows — agent-based models in Unit II, parallel simulation in Unit III, statistics in Unit IV, and result analysis in Unit V — assumes that you can answer three questions about any simulation you meet: how does its clock advance, what kind of state does it carry, and how much of its output do we believe.

1. Systems, Models and Simulation

The order of those three words matters. We never simulate a system directly; we simulate a model of it. Every claim a simulation makes is therefore a claim about the model, and it transfers to the real world only as far as the model is valid. This single sentence is the reason validation (Unit V) exists as a topic at all.

1.1 Why simulate at all?

1. The system does not exist yet. A new airport terminal, a new cache hierarchy, a new epidemic-control policy — you cannot measure what is not built.
2. Experimenting on the real system is unsafe, unethical or illegal. You may not deliberately overload a live power grid or infect a population to test a policy.
3. The analytical model is intractable. Queueing theory gives closed forms for a handful of idealised cases; real networks with priorities, blocking and correlated arrivals have none.
4. Real experiments are too slow or too fast. Galaxy formation takes 10⁹ years; a transistor switch takes 10⁻¹² s. Simulated time can be compressed or dilated at will.
5. We need many repetitions. Rare-event risk (a once-in-200-year flood) can be estimated by running the model ten million times.
6. We need controllability and repeatability. A simulation can be re-run with exactly one parameter changed — something the real world never permits.

1.2 Classification of models

1.3 The simulation study life cycle

A simulation study is a research process, not a programming exercise. The standard sequence (Banks et al.) is:

1. Problem formulation and objectives — write down the question the model must answer.
2. Conceptual model building — entities, state, events, assumptions, level of detail.
3. Data collection — arrival rates, service times, failure rates; fit distributions (Unit IV).
4. Model translation — implement in a language or package.
5. Verification — “Did I build the model right?” (code is faithful to the conceptual model).
6. Validation — “Did I build the right model?” (model is faithful to reality). Covered fully in Unit V.
7. Experimental design — run length, warm-up period, number of replications, scenarios.
8. Production runs and statistical analysis of output.
9. Documentation, reporting and implementation of the recommendation.

2. Handling Stepped and Event-Based Time

A dynamic simulation needs a simulation clock: a variable holding the current value of simulated time, which is entirely separate from wall-clock time. There are exactly two ways to advance it.

2.1 Time-stepped (fixed-increment) simulation

The main loop is trivially simple, which is exactly why it is used everywhere in physics, graphics and games:

t = 0
while t < T_end:
    for each entity e:            # order matters; see caution below
        e.update(dt)
    record_statistics(t)
    t = t + dt

Choosing Δt is the whole art. Too large and events are missed or the numerical integration becomes unstable; too small and the run takes forever, most ticks doing nothing. A workable rule is Δt ≤ one-tenth of the fastest time constant in the system.

2.2 Event-based (discrete-event) simulation

Three data structures define a DES engine:

1. The simulation clock t.
2. The state — queue lengths, server busy/idle flags, counters.
3. The future event list (FEL) — a priority queue of (timestamp, event-type, entity) records ordered by timestamp.

schedule(first_arrival, t = 0)
while FEL not empty and t < T_end:
    (t, event) = FEL.pop_min()      # the clock JUMPS to t
    handle(event)                   # may change state and schedule new events
    accumulate_statistics()

Ties and determinism

Two events with identical timestamps must be broken deterministically (by a priority field, or by insertion sequence number), otherwise the same seed gives different answers on different runs or machines — a reproducibility failure that is very hard to debug later.

2.3 Comparison and choice

2.4 Mixed and adaptive time advance

Real engines often combine the two. A network simulator may integrate a physical-layer signal with a fixed step while handling packet arrivals as events; a game engine uses a fixed step for physics but an event queue for collisions and AI triggers. Adaptive time-stepping (Section 4.4) sits in between: the step shrinks where the solution changes fast and grows where it is smooth.

3. Discrete versus Continuous Modelling

3.1 The same system, modelled both ways

Population growth is the standard classroom pair, and is also Experiment 2 in your laboratory.

These are not the same model. The continuous logistic equation always converges monotonically to the carrying capacity K. Its discrete counterpart, for growth rates above roughly r = 2, oscillates; above about 2.57 it becomes chaotic. Discretising a continuous model can therefore introduce behaviour that the original system does not have — a point worth one full paragraph in any answer on this topic.

3.2 Choosing between them

1. Population size. With 20 machines, integrality matters (you cannot have 3.7 machines) → discrete. With 10⁹ molecules, the fluid limit is excellent → continuous.
2. Question asked. If the answer is a mean flow rate, continuous suffices. If the answer is “what fraction of customers wait more than 5 minutes”, individual identity is needed → discrete.
3. Availability of data. Rate constants favour ODEs; logged timestamps favour discrete-event models.
4. Cost. Continuous models scale with the number of state variables; discrete models scale with the number of entities and events.

3.3 Combined (continuous–discrete) simulation

Many engineering systems are genuinely both. A chemical batch reactor has continuous temperature and concentration, but a discrete valve that opens when concentration crosses a threshold. Such models are called combined or hybrid (Section 7). The technical difficulty is state-event detection: the exact instant of threshold crossing lies inside an integration step, so the solver must detect the sign change of a zero-crossing function and then bisect or interpolate back to locate the crossing time before firing the discrete event.

4. Numerical Techniques

Continuous models must be discretised before a computer can execute them. The numerical method chosen determines the accuracy, the stability and much of the cost of the whole simulation.

4.1 Numerical integration of ODEs

Given the initial value problem dy/dt = f(t, y) with y(t₀) = y₀, and step h:

with k₁ = f(t_n, y _n), k₂ = f(t_n + h/2, y_n + hk₁/2), k₃ = f(t_n + h/2, y_n + hk₂/2), k₄ = f(t_n + h, y_n + hk₃).

4.2 Stability and stiffness

Accuracy is not the only concern; a method can be accurate in principle and still explode. For the test equation dy/dt = λy with λ < 0, explicit Euler is stable only if |1 + hλ| < 1, that is h < 2/|λ|. Backward Euler is stable for every h > 0 (it is A-stable), which is why implicit methods are used for stiff systems — systems containing time constants that differ by many orders of magnitude, where an explicit method would be forced down to the smallest constant even though the interesting behaviour is slow.

4.3 Other numerical machinery you will meet

• Root finding — bisection, Newton–Raphson; used for state-event detection and for solving the implicit step of an implicit integrator.
• Linear algebra — LU, Gauss–Seidel, conjugate gradient; the inner loop of every mesh-based simulation (Unit II).
• Interpolation and quadrature — reconstructing values between grid points, computing integrals of the output.
• Finite difference / finite element / finite volume — discretisation of PDEs in space, giving the huge sparse systems that motivate Unit III.

4.4 Adaptive step control

Embedded pairs such as Runge–Kutta–Fehlberg (RKF45) compute two estimates of different order at each step; their difference estimates the local error, and the step is accepted, rejected or resized to keep that error near a tolerance. This gives accuracy where the solution is fast-changing and speed where it is not.

5. Sources and Propagation of Error

5.1 The five sources of error

1. Modelling error. The gap between reality and the conceptual model — assumptions of independence, neglected friction, homogeneous mixing. Usually the largest error, and the one no numerical refinement can reduce.
2. Data / input error. Measurement noise, wrongly fitted distributions, outdated parameters.
3. Truncation (discretisation) error. From replacing a limit with a finite quantity: a derivative by a difference quotient, an infinite series by a partial sum, continuous time by a step h.
4. Round-off error. From finite floating-point precision (IEEE 754 double: about 16 significant decimal digits, machine epsilon ≈ 2.2×10⁻¹⁶).
5. Statistical (sampling) error. In stochastic models, from using a finite number of replications; decreases only as 1/√n (Unit IV).

5.2 Propagation of error

Errors do not stay where they are born. For a smooth function y = f(x ₁, …, x_n) with small independent input errors, first-order propagation gives:

The partial derivatives are exactly the sensitivity coefficients of Unit IV, so error propagation and sensitivity analysis are two views of the same computation.

Conditioning and stability

• A problem is ill-conditioned if small input changes cause large output changes; the condition number measures this. No algorithm can rescue an ill-conditioned problem.
• An algorithm is unstable if it amplifies round-off that a better algorithm would not. This can be fixed by choosing a different method.
• In chaotic systems (Lorenz, n-body, weather) errors grow exponentially: e(t) ≈ e₀e^λt with λ the largest Lyapunov exponent. Long-run trajectories are then meaningless individually, and only statistical properties of the attractor are predictable.

5.3 Practical rules for controlling error

1. Never test floating-point numbers for equality; compare against a tolerance.
2. Avoid subtracting nearly equal numbers (catastrophic cancellation); rearrange the formula algebraically. The classic fix is the stable quadratic-root formula.
3. Sum many small numbers in ascending order, or use Kahan compensated summation.
4. Do a grid-refinement (convergence) study: halve h, and confirm that the answer changes by the amount the method's order predicts.
5. Report a confidence interval, never a bare number, for stochastic output.
6. Keep a fixed random seed for debugging and vary it for production replications.

6. Stochastic Modelling and Simulation

6.1 Why randomness belongs in the model

Uncertainty is not an imperfection to be averaged away at the input. Because most performance measures are non-linear, the mean of the outputs is not the output of the mean — the “flaw of averages”. A road designed for the average traffic load is congested half the time; a server sized for mean demand has unbounded queues at the peak.

6.2 The machinery (previewed here, detailed in Unit IV)

1. Pseudo-random number generators (PRNGs) produce a deterministic stream u₁, u₂, … that behaves statistically like independent Uniform(0,1) draws. Modern choices: Mersenne Twister, PCG, xoshiro256++. Requirements: long period, good equidistribution, speed, and reproducibility from a seed.
2. Random variate generation converts uniforms into the required distribution — inverse transform, acceptance–rejection, convolution, composition.
3. Replication: run n independent repetitions with different substreams and report the mean with a confidence interval.
4. Variance reduction: common random numbers, antithetic variates, control variates, importance sampling — techniques that buy accuracy without buying CPU time.

The 1/√n law is worth memorising: to halve the confidence interval you must quadruple the number of replications. This is the single most important economic fact about stochastic simulation, and it is the reason Unit III (parallelism) and variance reduction both matter.

6.3 Common stochastic model families

• Markov chains — discrete or continuous time, memoryless transitions.
• Poisson processes — the standard model of “random arrivals” with rate λ; inter-arrival times are Exponential(λ).
• Random walks and Brownian motion — diffusion, stock prices.
• Stochastic differential equations — dX = μdt + σdW, solved by the Euler–Maruyama scheme.
• Monte Carlo methods — estimation of integrals, probabilities and rare events by sampling (Unit II, Section on Monte Carlo).

7. Optimization in Simulation Models

Three properties make this hard and distinguish it from ordinary mathematical programming:

1. The objective is a black box — no formula, hence no gradient.
2. Each evaluation is noisy — two evaluations of the same x differ.
3. Each evaluation is expensive — minutes to hours, so the budget is a few hundred evaluations, not millions.

7.1 Families of methods

7.2 Design of experiments as the cheap alternative

Before optimising, screen. A 2^k factorial or fractional-factorial design identifies which of k factors actually matter, at a fraction of the cost of a full grid search. Latin hypercube sampling covers a continuous space evenly with few runs. Optimisation is then carried out only over the two or three factors that survived screening.

8. Hybrid and Multi-Scale Modelling

8.1 Why hybridise

1. No single paradigm fits a whole real system: a hospital has continuous disease progression, discrete patient flow through resources, and autonomous decision-making staff.
2. Detail is needed only in part of the domain; the rest can run in a cheaper representation.
3. Legacy models already exist in different formalisms and must be federated rather than rewritten (see HLA, Section 9).

8.2 Coupling patterns

• Hierarchical (scale-bridging). A fine-scale model supplies parameters to a coarse-scale one — molecular dynamics giving a viscosity to a fluid solver.
• Concurrent (domain decomposition). Different regions use different models at the same time, exchanging boundary data — atomistic near a crack tip, continuum elsewhere.
• Sequential / one-way. Output of model A becomes input of model B (weather → crop yield).
• Feedback / two-way. Both models influence each other every coupling interval; needs a consistent coupling time step and often iteration to convergence.

8.3 The hard problems in coupling

1. Time-scale mismatch. One model steps in nanoseconds, the other in hours; the coupling interval and the sub-cycling scheme must be chosen explicitly.
2. Unit, semantic and representation mismatch. Converting a continuous concentration into an integer number of agents (and back) is not neutral — rounding systematically biases small populations.
3. Consistency and conservation. Mass, energy or entity count must not be created or destroyed at the interface.
4. Stability of the coupled system. Two individually stable solvers can be unstable when coupled explicitly.
5. Compounded validation. Each sub-model and every interface must be validated; the credibility of the whole is bounded by the weakest link.

9. Modelling and Simulation Standards

Standards exist so that models built by different teams, in different tools, at different times can be trusted, reused and connected. They fall into three groups.

9.1 Interoperability standards

• HLA — High Level Architecture (IEEE 1516). The dominant standard for distributed simulation. A federation of federates communicates through a Run-Time Infrastructure (RTI) using a shared Federation Object Model. The RTI provides six service groups, of which time management (ensuring events are delivered in timestamp order) and data distribution management are the ones to name in an answer.
• DIS — Distributed Interactive Simulation (IEEE 1278). Older, packet-based (protocol data units), used for real-time platform-level military training.
• FMI — Functional Mock-up Interface. A tool-independent standard for exchanging and co-simulating dynamic models as Functional Mock-up Units; the norm in automotive and control engineering.
• TENA and DDS — test-range and publish/subscribe middleware used where real hardware is in the loop.

9.2 Process and credibility standards

• DSEEP (IEEE 1730) — Distributed Simulation Engineering and Execution Process: the recommended life cycle for building a federation.
• VV&A — Verification, Validation and Accreditation (IEEE 1516.4, US DoD guidance): a formal, auditable process ending in a decision that a model is fit for a stated purpose.
• ASME V&V 10 / 20 — verification and validation in computational solid mechanics and fluid dynamics.
• SISO product standards, e.g. SRML, MSDL, C-BML, for scenario and behaviour exchange.

9.3 Model representation and reporting standards

• DEVS (Discrete Event System Specification) — a formal, mathematically defined modelling formalism with atomic and coupled models; the reference semantics for discrete event simulation and a common target for model exchange.
• SBML / CellML / NeuroML — domain markup languages for systems biology, physiology and neuroscience.
• SED-ML — describes the experiment (which model, which solver, which outputs), so that a published result can be reproduced.
• ODD protocol (Overview, Design concepts, Details) — the accepted template for describing an agent-based model in a paper so that others can reimplement it.
• SysML / Modelica — standardised languages for system architecture and for equation-based physical modelling.

10. Simulation Software and Tools

This course is about building simulation environments, not merely operating a package — so you should be able to justify the choice between writing a simulator and buying one.

10.1 Criteria for selecting a tool

1. Does its world view (process interaction, event scheduling, activity scanning, agent-based, equation-based) match your model?
2. Statistical support: distribution fitting, replication control, confidence intervals, variance reduction.
3. Scalability and parallel execution; ability to run headless in batch on a cluster.
4. Extensibility: can you insert custom code, or are you trapped inside the GUI?
5. Verification and debugging support: tracing, step-through, event logs, seed control.
6. Interoperability: HLA/FMI support, standard input and output formats.
7. Licence cost, licence terms, and the size of the user community; longevity of the vendor.
8. Reproducibility: version pinning, scripted (not click-driven) experiments.

import simpy, random

def customer(env, name, server):
    with server.request() as req:          # join the queue
        yield req                          # wait for the server
        yield env.timeout(random.expovariate(1/3.0))   # service

def source(env, server):
    i = 0
    while True:
        yield env.timeout(random.expovariate(1/4.0))   # inter-arrival
        env.process(customer(env, i, server)); i += 1

env = simpy.Environment()
server = simpy.Resource(env, capacity=1)
env.process(source(env, server))
env.run(until=1000)

11. Ethical and Practical Considerations

Simulation results are used to justify decisions that affect money, safety and lives. The ethical obligations are therefore professional obligations, not optional extras.

11.1 Ethical issues

1. Honest reporting of assumptions and limitations. Every model is wrong in stated ways; concealing the assumptions makes a result rhetorical rather than scientific.
2. Fitness for purpose. A model validated for one operating range must not be quoted outside it. Accreditation exists precisely to record the domain of validity.
3. Avoiding advocacy modelling. Choosing parameters, scenarios or output measures that produce a pre-determined conclusion is falsification, however subtly done.
4. Transparency and reproducibility. Publish the model, the parameters, the seeds and the version. An unpublishable model cannot be checked and should not be believed.
5. Data privacy and consent. Agent-based models of health, mobility or social behaviour are often built from personal data; anonymisation, aggregation, consent and applicable data-protection law all apply.
6. Bias and fairness. A model calibrated on data from one group and applied to another can systematically disadvantage people — in policing, credit, healthcare or infrastructure planning.
7. Communication to non-experts. Presenting a stochastic projection as a prediction, or hiding uncertainty behind a single smooth curve, misleads the decision maker even when every number is correct.
8. Dual use and misuse. Models of infrastructure, epidemics or weapons can be used to attack as well as to protect; access and publication need judgement.
9. Professional codes. The ACM/IEEE Software Engineering Code of Ethics and the SCS/SISO codes for simulationists apply to this work directly.

11.2 Practical considerations

1. Data quality and availability usually limits accuracy far more than the algorithm does. Budget most of the project time for data.
2. The right level of detail. Detail costs data, runtime and credibility. A model should be as simple as the question permits — and no simpler.
3. Computational budget. Run length, warm-up, replications and scenario count multiply; plan them before running anything.
4. Software engineering discipline. Version control, unit tests on the event logic, regression tests on known analytical cases, and a recorded seed for every reported figure.
5. Documentation. The model description (ODD or equivalent) must let a competent stranger reimplement the model.
6. Stakeholder involvement. A model that domain experts have not reviewed will not be trusted, and usually should not be.

12. Unit Summary

• A simulation executes a model, not the system; its authority is bounded by validation.
• Two clock mechanisms exist: time-stepped (fixed Δt, simple, wasteful when idle) and event-based (jumps to the next event, exact timing, needs a future event list).
• State is either discrete (jumps, countable, individual entities) or continuous (smooth, differential equations, aggregates); combined models need state-event detection.
• Numerical methods trade accuracy against cost and stability: Euler O(h), trapezoidal O(h²), RK4 O(h⁴); stiff problems require implicit methods.
• Five error sources: modelling, data, truncation, round-off, statistical. Truncation falls and round-off rises as h shrinks, so an optimal step exists.
• Stochastic models give random output: replicate, report confidence intervals, remember the 1/√n law, and use variance reduction.
• Simulation optimization deals with a noisy, expensive, gradient-free objective: ranking and selection, metaheuristics, and surrogate/metamodel methods.
• Hybrid and multi-scale models couple paradigms and scales; the difficulty lies in the interfaces.
• Standards (HLA, FMI, DEVS, DSEEP, VV&A, ODD) provide interoperability, credibility and reproducibility.
• Ethical practice = honest assumptions, stated domain of validity, published data and seeds, uncertainty communicated, privacy respected.

12.1 Key terms

System · model · simulation · simulation clock · time-stepped · discrete-event · future event list · state event · truncation error · round-off error · stiffness · A-stability · PRNG · replication · confidence interval · variance reduction · metamodel · ranking and selection · federation / federate / RTI · DEVS · VV&A · ODD protocol.

12.2 Practice questions

Short answer (2–3 marks each)

1. Define simulation. State two situations in which simulation is preferred to analytical solution.
2. Differentiate between verification and validation with one example of each.
3. What is a future event list and why must it be a priority queue?
4. Distinguish truncation error from round-off error.
5. Why does halving the confidence-interval width require four times as many replications?
6. What is a stiff system, and which class of integrators is used for it?
7. State any three purposes served by simulation standards.

Medium answer (5 marks each)

1. Write the algorithm for a time-stepped simulation and for an event-driven simulation, and state two advantages of each.
2. Explain the sources of error in a simulation study and sketch how total error varies with the step size h.
3. Explain, with the M/M/1 queue as an example, how a discrete-event simulation advances time and accumulates statistics.
4. Discuss the difficulties specific to simulation optimization and name one method from each of three families.
5. What is multi-scale modelling? Describe two coupling patterns and two problems that arise at the interface.

Long answer (10 marks each)

1. Compare stepped and event-based time handling in simulations under at least six criteria, with pseudocode and one worked example showing the cost difference.
2. Compare discrete and continuous modelling. Illustrate with a population-growth model formulated both ways, and explain how the discretisation can introduce behaviour absent from the continuous model.
3. Describe the numerical techniques used in continuous simulation. Derive or state Euler and RK4, discuss order of accuracy, stability, stiffness and adaptive step control.
4. Explain stochastic simulation end to end: pseudo-random generation, variate generation, replication, confidence intervals and variance reduction.
5. Discuss the ethical and practical considerations in modelling and simulation, with examples of how each can be violated in practice.

12.3 Further reading

• J. Banks (ed.), Handbook of Simulation: Principles, Methodology, Advances, Applications and Practice, Wiley — chapters 1–3.
• A. M. Law, Simulation Modeling and Analysis — the standard reference for the study life cycle, input modelling and output analysis.
• S. Asmussen and P. W. Glynn, Stochastic Simulation: Algorithms and Analysis, Springer — for Sections 6 and 7.
• B. P. Zeigler et al., Theory of Modeling and Simulation — for DEVS and the formal treatment of time.
• K. Al-Begain and A. Bargiela (eds.), Seminal Contributions to Modelling and Simulation, Springer.